Go goroutine vs Java 虚拟线程 vs Kotlin 协程

func handle(conn net.Conn) {
    buf := make([]byte, 1024)
    n, _ := conn.Read(buf)       // 看起来阻塞，编译器自动插入挂起点
    conn.Write(buf[:n])           // 同上
}

// 起 10 万个，毫无压力
for i := 0; i < 100000; i++ {
    go handle(conn)               // go 关键字，够简单
}

Go 的每一个函数调用入口都是一个潜在的挂起点（栈检查 safepoint）。你写的 conn.Read()看起来阻塞，编译器帮你切成状态机，你完全不知道——也不需要知道。

// 和普通 Thread 写法一模一样
Thread.startVirtualThread(() -> {
    socketChannel.read(buffer);      // 看起来阻塞
    process(buffer);
});

// 老代码不用改，只需换一个工厂方法
// 老：
ExecutorService pool = Executors.newCachedThreadPool();          // 平台线程池

// 新：
ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor(); // 虚拟线程池

// 同一套 API，底层从 OS 线程切换到了用户态调度

suspend fun fetchData(): String {     // ← suspend 关键字！
    delay(1000)
    return "data"
}

// 不标记 suspend 就不能调 delay
fun normalFunc() {
    delay(1000)   //   编译错误！不在 suspend 函数里不能调挂起函数
}

suspend fun a() { b() }        //   suspend 调 suspend
suspend fun b() { delay(100) } // 

fun c() {
    a()                        //   编译错误！普通函数不能调 suspend
    delay(100)                 //   编译错误！
}

// 必须这样：
fun c() = runBlocking {        // 搭个桥
    a()                        // 
}

// Go：所有函数都能挂起（里面有没有 I/O 你根本看不出来）
func a() { b() }               //   b 会挂起，a 也自动会挂起
func b() { conn.Read(buf) }    // 看起来是普通函数，实际挂起

func c() {
    a()                        //   普通函数，可以调
}

// Java：也没有染色，完全兼容老 API
void a() { b(); }              // 
void b() { socket.read(); }    // 看起来阻塞，在虚拟线程里挂起

void c() {
    Thread.startVirtualThread(() -> a());  //   普通方法，不改任何签名
}